В начале апреля компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью командных сценариев PowerShell до версии PowerCLI 12.0. Напомним, что прошлая версия PowerCLI 11.5 вышла осенью прошлого года.
Давайте посмотрим, что нового появилось в двенадцатой версии фреймворка:
Добавлены командлеты для управления хостовой сетью ESXi
Еще в vSphere 6.0 появилась поддержка сетевых стеков хостов ESXi. Она позволяет назначить различные шлюзы для адаптеров VMkernel в целях маршрутизации трафика. Через PowerCLI можно использовать ESXCLI или API для управления этой функциональностью с помощью командлетов Get-VMHostNetworkStack и Set-VMHostNetworkStack. Новый параметр называется "NetworkStack", он был добавлен в командлет New-VMHostNetworkAdapter:
Добавлены командлеты для управления решением HCX
Появились новые командлеты для управления пространствами имен
Командлеты для управления службами Trusted Host Services
Командлеты для управления диском гостевой ОС виртуальных машин (VM Guest Disk management)
Теперь раздел гостевой ОС можно замапить на VMDK-диск (пока только для Windows-систем). Для этого потребуется vSphere 7 и VMware Tools не ниже 11-й версии. Эту возможность можно использовать с помощью командлета Get-VMGuestDisk:
Новые командлеты для управления VMware Cloud on AWS
Новые командлеты для vSAN:
Get-VsanFileServiceDomain
New-VsanFileServiceDomain
Set-VsanFileServiceDomain
Remove-VsanFileServiceDomain
New-VsanFileServiceIpConfig
Get-VsanFileShare
New-VsanFileShare
Set-VsanFileShare
Remove-VsanFileShare
New-VsanFileShareNetworkPermission
Add-VsanFileServiceOvf
Get-VsanFileServiceOvfInfo
Новый модуль для управления службами VMware Cloud Services
Добавлена поддержка vSphere 7.0
Добавлена поддержка vRealize Operations 8.0
Обновлена поддержка модулей License и vROps, а также командлета Open-VMConsoleWindow для использования на различных платформах
Поддержка Move-VM для сетей opaque networks
Добавлена поддержка последних обновлений PowerShell 7.0:
Скачать VMware PowerCLI 12.0 можно по этой ссылке. Полезные ресурсы:
На днях на сайте проекта VMware Labs появилась полезная администраторам vSphere штука - утилита vSphere Replication Capacity Planning, позволяющая определить реальное потребление трафика репликации виртуальными машинами и размер передаваемой дельты данных. Это позволяет планировать сетевую инфраструктуру и принимать решения о выделении канала еще до того, как вы включите репликацию для всех своих виртуальных машин.
Утилита Replication Capacity Planning показывает графики, касающиеся объема передачи сетевого трафика LWD (lightweight delta - изменения с момента последней репликации) во времени, а также метрики по размеру дельты в различных временных масштабах - часы, дни, недели и месяцы.
Также в результате работы этого средства для виртуальной машины будет показано, какой объем вычислительных ресурсов и хранилища под реплики вам потребуется на целевой площадке (без учета актуальной политики хранилищ там):
Решение vSphere Replication Capacity Planning развертывается как виртуальный модуль (Virtual Appliance), для его работы потребуется VMware ESXi 6.0 или более поздней версии. Скачать его можно по этой ссылке. Документация доступна здесь.
На сайте проекта VMware Labs очередное обновление - вышел апдейт VMware OS Optimization Tool
b1150. Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач. О прошлой версии этой утилиты b1140 мы писали вот тут.
Давайте посмотрим, что нового есть в апрельском апдейте OS Optimization Tool:
Появилась поддержка Windows 10 version 2004 (добавлено во встроенный шаблон Windows 10 1809 – XXXX-Server 2019).
Добавлено множество оптимизаций для Windows 10 и Windows Server.
Новые настройки для приложений:
Office 2013/2016/2019:
Отключить стартовый экран
Отключить анимации
Отключить аппаратное ускорение
Internet Explorer 11 и браузер Edge:
Возможность добавить пустую домашнюю страницу
Не показывать мастер первого запуска
Отключить аппаратное ускорение
Adobe Reader 11 и DC
Отключить аппаратное ускорение
Множество дополнительных мелких оптимизаций
Несколько новых оптимизаций для служб Windows и запланированных задач, уменьшающих время инициализации ОС и увеличивающих производительность.
Несколько кнопок было переименовано и реорганизовано, чтобы лучше отражать суть того, что они делают.
Улучшения структуры файла ответов Sysprep.
Новые настройки для задач во время операции Generalize.
Автоматизация использования утилиты SDelete для обнуления блоков на диске (полезно при клонировании диска).
Создание локальных групповых политик для компьютера и пользователя, которые можно посмотреть с помощью утилит RSOP и GPEdit.
Поддержка командной строки для шага Generalize.
Finalize можно запускать без указания шаблона.
Удалены устаревшие шаблоны для Horizon Cloud и App Volumes.
Мы много писали о том, что нового появилось в обновленной платформе виртуализации VMware vSphere 7, которая недавно стала доступной для загрузки. Сегодня мы поговорим о том, чего больше нет в vSphere, ведь многие администраторы привыкли использовать некоторые средства, поэтому, возможно, подождут с апгрейдом. Об этих запланированных изменениях мы писали еще в 2017 году.
1. Больше нет vSphere Web Client на базе Flash
Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.
Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).
2. Больше нет внешнего PSC (Platform Services Controller)
Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).
С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:
3. Больше нет VMware vCenter for Windows
Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.
VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
4. Больше нет Update Manager Plugin
На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.
Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.
5. Больше нет VNC-сервера в ESXi
Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.
Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.
6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)
В эту категорию попали:
VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.
Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7, а также функциональности нового механизма динамического распределения нагрузки VMware DRS 2.0. Среди новых возможностей DRS мы упоминали про функции Assignable Hardware, которые позволяют назначить профили устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU для первоначального размещения виртуальных машин в кластере.
Сегодня мы поговорим об этой технологии в целом. Ранее виртуальные машины, использовавшие технологии DirectPath I/O или vGPU, привязывались к физическому адресу устройства, который включал в себя адрес расположения устройства на конкретной шине PCIe конкретного хоста ESXi. Это делало невозможным использование такой ВМ на других серверах кластера, что, конечно же, делало невозможным и работу технологий HA и DRS, которые являются критически важными в современных датацентрах.
Теперь же технология Assignable Hardware вводит новый уровень абстракции, который включает в себя профиль с возможностями устройств, требующихся для виртуальной машины. Таких профилей два - для технологии Dynamic DirectPath I/O и для NVIDIA vGPU:
Таким образом, технология Assignable Hardware позволяет отделить виртуальную машину от конкретного устройства и дать ей возможность быть запущенной на другом хосте ESXi с таким же устройством (или даже другим, но поддерживающим определенный набор функций).
Теперь при настройке виртуальной машины у вас есть выбор одного из следующих вариантов для устройства PCIe:
DirectPath I/O (legacy-режим, без интеграции с HA и DRS)
Dynamic DirectPath I/O
NVIDIA vGPU
После того, как вы выберете нужный профиль оборудования, механизм DRS сможет разместить машину на хосте ESXi с поддержкой нужных функций для ВМ.
На скриншоте выше, во второй опции Select Hardware, также есть лейбл "GPGPU example" - это возможность задать определенным устройствам метки таким образом, чтобы при выборе размещения ВМ использовались только устройства хостов с данными метками (при этом модели устройств могут отличаться, например, NVIDIA T4 GPU и RTX6000 GPU). Либо можно выбрать вариант использования только идентичных устройств.
Назначить метку можно во время конфигурации PCIe-устройств. В гифке ниже показано, как это делается:
При использовании NVIDIA vGPU для виртуальной машины выделяется только часть устройства. Поддержка горячей миграции vMotion для машин, использующих vGPU, уже была анонсирована в VMware vSphere 6.7 Update 1. Теперь эта поддержка была расширена, в том числе для DRS, который теперь учитывает профили vGPU.
Ну и в видео ниже вы можете увидеть обзор технологии Assignable Hardware:
Таги: VMware, vSphere, Hardware, NVIDIA, vGPU, VMachines, DRS, vMotion, HA
Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 7, среди которых мы вкратце рассказывали о нововведениях механизма динамического распределения нагрузки на хосты VMware DRS. Давайте взглянем сегодня на эти новшества несколько подробнее.
Механизм DRS был полностью переписан, так как его основы закладывались достаточно давно. Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом, то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин:
При этом раньше DRS запускался каждые 5 минут. Теперь же этот механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness). Это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness. Расчеты по памяти теперь основываются на Granted Memory вместо стандартного отклонения по кластеру.
Мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (Memory Overcommit), поэтому вместо "Active Memory" DRS 2.0 использует параметр "Granted Memory".
VM Happiness - это основной KPI, которым руководствуется DRS 2.0 при проведении миграций (то есть главная цель всей цепочки миграций - это улучшить этот показатель). Также эту оценку можно увидеть и в интерфейсе:
Как видно из картинки, DRS Score квантуется на 5 уровней, к каждому из которых относится определенное количество ВМ в кластере. Соответственно, цель механизма балансировки нагрузки - это увеличить Cluster DRS Score как агрегированный показатель на уровне всего кластера VMware HA / DRS.
Кстати, на DRS Score влияют не только метрики, касающиеся производительности. Например, на него могут влиять и метрики по заполненности хранилищ, привязанных к хостам ESXi в кластере.
Надо понимать, что новый DRS позволяет не только выровнять нагрузку, но и защитить отдельные хосты ESXi от внезапных всплесков нагрузки, которые могут привести виртуальные машины к проседанию по производительности. Поэтому главная цель - это держать на высоком уровне Cluster DRS Score и не иметь виртуальных машин с низким VM Hapiness (0-20%):
Таким образом, фокус DRS смещается с уровня хостов ESXi на уровень рабочих нагрузок в виртуальных машинах, что гораздо ближе к требованиям реального мира с точки зрения уровня обслуживания пользователей.
Если вы нажмете на опцию View all VMs в представлении summary DRS view, то сможете получить детальную информацию о DRS Score каждой из виртуальных машин, а также другие важные метрики:
Ну и, конечно же, на улучшение общего DRS Score повлияет увеличения числа хостов ESXi в кластере и разгрузка его ресурсов.
Кстати, ниже приведен небольшой обзор работы в интерфейсе нового DRS:
Еще одной важной возможностью нового DRS является функция Assignable Hardware. Многие виртуальные машины требуют некоторые аппаратные возможности для поддержания определенного уровня производительности, например, устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU. В этом случае теперь DRS позволяет назначить профили с поддержкой данных функций для первоначального размещения виртуальных машин в кластере.
В видео ниже описано более подробно, как это работает:
Ну и надо отметить, что теперь появился механизм Scaleable Shares, который позволяет лучше выделять Shares в пуле ресурсов с точки зрения их балансировки. Если раньше высокий назначенный уровень Shares пула не гарантировал, что виртуальные машины этого пула получат больший объем ресурсов на практике, то теперь это может использоваться именно для честного распределения нагрузки между пулами.
Этот механизм будет очень важным для таких решений, как vSphere with Kubernetes и vSphere Pod Service, чтобы определенный ярус нагрузок мог получать необходимый уровень ресурсов. Более подробно об этом рассказано в видео ниже:
На сайте проекта VMware Labs появилось очередное обновление - виртуальный модуль Ubuntu OVA for Horizon версии 1.2. С помощью этого модуля VDI-администраторы могут быстро развернуть инфраструктуру виртуальных ПК на Linux-платформе, получив уже все необходимые настройки и оптимизации в рамках OVA-пакета. Напомним, что о версии 1.1 этого средства мы писали вот тут.
Вот что нового появилось в образе Ubuntu OVA for Horizon версии 1.2:
Поддержка минимально Horizon 7.11 / Horizon Client 5.3 и более поздних версий
Поддержка минимально vSphere 6.7 и более поздних версий
Обновленный базовый образ шаблона OVA на Ubuntu 18.04.4 LTS
На Reddit коллеги заметили, что при включении технологии Turbo Boost в процессорах Intel, из виртуальной машины увеличения производительности не наблюдается. Напомним, что Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP).
При этом емкость CPU показывается прежней, даже при создании существенной нагрузки на процессор:
В комментариях люди правильно отвечают, что поскольку Turbo Boost - это аппаратная возможность, гостевая система виртуальной машины не ловит отображение увеличения аппаратной мощности в виртуальную машину. При этом если вы посмотрите на виртуальную машину с 4 процессорами 2.4 ГГц с уровня хоста ESXi с включенным Turbo Boost до 3 ГГц, вы увидите утилизацию процессора 4*3=12 ГГц.
То есть гостевая система вполне будет использовать преимущества этой технологии, но отображать утилизацию процессора она будет в соответствии с его номинальной мощностью.
В декабре мы писали о новой версии решения VMware OS Optimization Tool, которое предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.
В январе вышла новая версия (билд b1140) этого решения. Давайте посмотрим, что в ней появилось нового:
Новая кнопка на экране результатов задач, которая позволяет сохранить страницу как HTML-файл.
Новая опция, которая упрощает задачу запуска Sysprep с использованием стандартного файла ответов. Теперь можно отредактировать файл ответов до запуска Sysprep для него.
Новая опция по автоматизации задач в рамках этапа финализации (они переехали из common options), которые запускаются как последний шаг перед тем, как Windows будет выключена, чтобы ВМ была использована в решении VMware Horizon. Она включает в себя задачи по system clean up (очистка диска, NGEN, DISM и задача Compact). Ранее эти задачи были доступны в диалоге опций командной строки. Также можно чистить лог событий, информацию о серверах KMS и отпускании IP-адреса.
Новая вкладка опций Security - она позволяет быстро выбрать наиболее частые настройки безопасности. Они относятся к Bitlocker, Firewall, Windows Defender, SmartScreen и HVCI.
Добавлен параметр командной строки -o для запуска утилиты без применения оптимизаций (например, clean up).
Изменена дефолтная настройка на "не отключать Webcache", потому что это приводило к невозможности для браузеров Edge и IE сохранять файлы.
На днях компания Intel опубликовала руководство по безопасности Security Advisory INTEL-SA-00329, в котором описаны новые обнаруженные уязвимости в CPU, названные L1D Eviction Sampling (она же "CacheOut") и Vector Register Sampling. Прежде всего, надо отметить, что обе этих уязвимости свежие, а значит исправления для них пока не выпущено.
Соответственно, VMware также не может выпустить апдейт, пока нет обновления микрокода CPU от Intel. Когда Intel сделает это, VMware сразу выпустит патч, накатив который на VMware vSphere вы избавитесь от этих потенциальных уязвимостей.
Vector Register Sampling (CVE-2020-0548). Эта уязвимость является пережитком бага, найденного в подсистеме безопасности в ноябре прошлого года. Она связана с атаками типа side-channel, о которых мы писали вот тут. В рамках данной атаки можно использовать механизм Transactional Synchronization Extensions (TSX), представленный в процессорах Cascade Lake. О прошлой подобной уязвимости можно почитать вот тут. А список подверженных уязвимости процессоров Intel можно найти тут.
L1D Eviction Sampling (CVE-2020-0549). Эта уязвимость (ее также называют CacheOut) позволяет злоумышленнику, имеющему доступ к гостевой ОС, получить доступ к данным из памяти других виртуальных машин. Более подробно об уязвимостях данного типа можно почитать на специальном веб-сайте. Также вот тут находится список уязвимых процессоров.
Следите за обновлениями VMware, патчи будут доступны сразу, как только Intel обновит микрокод процессоров. Достаточно будет просто накатить обновления vSphere - и они пофиксят уязвимости CPU.
Таги: VMware, Intel, Security, VMachines, vSphere, CPU
Интересный баг обнаружил Matt для своей виртуальной инфраструктуры, когда пытался клонировать виртуальные машины с выставленной опцией "customize this virtual machine’s hardware":
Оказалось, что после создания клона его VMDK-диск указывал на VMDK клонируемой машины, что, само собой, является серьезнейшим багом. После работы с техподдержкой оказалось, что баг не такой и частый, так как проявляется только когда в VMX-файле исходной машины параметр disk.enableuuid выставлен в значение TRUE (по умолчанию он отсутствует и применяется как FALSE).
Данный параметр иногда добавляется пользователями в соответствии с рекомендациями вендоров решений для резервного копирования и управления виртуальной средой - он позволяет убедиться в том, что VMDK диск предоставляет машине консистентный UUID для корректного монтирования.
Workaround для этого бага - это либо использовать для операций клонирования старый vSphere Web Client, либо делать это через PowerCLI. Можно также не использовать опцию "customize this virtual machine’s hardware", а настроить железо ВМ после выполнения клонирования. Также баг не проявляется если делать клонирование выключенной машины.
В сентябре этого года мы писали о новой версии пакета VMware Tools 11 для гостевых ОС виртуальных машин на платформе VMware vSphere. Одной из новых возможностей обновленной версии тулзов был читаемый с хоста параметр AppInfo для публикации информации о запущенных приложений внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается).
Недавно Вильям Ламм пояснил, как именно может работать этот механизм, который дает возможность получить данные о процессах в гостевой ОС и их свойствах.
Для начала начала надо включить Application Discovery в гостевой ОС с помощью утилиты VMwareToolbox. По умолчанию этот механизм отключен, чтобы не создавать дополнительную нагрузку на виртуальную машину.
Для включения нужно выполнить следующую команду:
Windows: VMwareToolboxCmd.exe config set appinfo enabled true
Linux: vmware-toolbox-cmd config set appinfo enabled true
Выглядит это таким образом:
После того, как сбор данных включен, они будут обновляться каждые 30 минут - то есть эта функция не предназначена для мониторинга процессов в реальном времени, а скорее для сбора информации об имеющихся в ВМ приложениях и их свойствах. Чтобы изменить интервал обновления, используйте следующие команды:
Linux: vmware-toolbox-cmd config set appinfo poll-interval <new value in seconds>
Windows: VMwareToolboxCmd.exe config set appinfo poll-interval <new value in seconds>
Например, AppInfo может собирать информацию о версии всех приложений, что может оказаться полезным при автоматизированном поиске устаревших версий приложений с помощью сценариев.
Вильям написал PowerCLI-скрипт Get-VMApplicationInfo.ps1, который принимает на вход виртуальную машину, а на выходе выдает информацию о процессах гостевой ОС с меткой времени сбора данных.
Результат работы сценария можно вывести в CSV-файл или в JSON-массив.
Ну а дальше уже можно фантазировать, для чего подобная информация может пригодиться именно в вашей виртуальной инфраструктуре.
Многим администраторам VMware vSphere иногда требуется собрать некоторые базовые сведения об имеющихся в виртуальной инфраструктуре виртуальных машинах и их гостевых системах. Традиционные способы сбора такой информации применимы лишь частично - ведь стандартный софт для собора ассетов не может взглянуть внутрь хостов ESXi и задокументировать их внутреннюю структуру. Также надо понимать, что софт, использующий ICMP-протокол (а именно команду ping) также не подходит для этой задачи, так как далеко не все системы сегодня отвечают на пинг.
Давайте посмотрим на способы, которые доступны для этой задачи:
1. Функция экспорта в vSphere Client.
Это самое первое, что вам следует сделать для решения проблемы инвентаризации ассетов в виртуальной среде. Кнопка экспорта находится в нижнем правом углу инвентори клиента. С помощью этой фичи можно выгрузить любое представление с нужными колонками в формат CSV:
Здесь вы сможете выгрузить то, чего больше не сможете выгрузить нигде, например, сведения о поддержке TPM, функциях безопасной загрузки Secure Boot для ESXi и гостевых ОС, поддержке Microsoft Device Guard & Credential Guard и функций шифрования VM Encryption.
2. Экспорт через PowerCLI.
PowerCLI, как вы знаете, может все, что может GUI, плюс несколько больше. Поэтому он вам может понадобиться для расширенных параметров виртуальной среды. Основные шаблоны для работы с PowerCLI можно найти здесь.
Вот так, например, работают командлеты Get-VM и Get-VMGuest:
А вот так Get-VMHost:
Результаты работы можно сохранить в текстовый файл с помощью командлета Out-File или в CSV-файл с помощью Export-Csv.
3. Утилита nmap.
Эта утилита знакома всем сетевым администраторам, ведь ей уже более 20 лет. Ее используют как в физической, так и в виртуальной среде для сбора информации о системах и сервисах, висящих на соответствующих портах. Для Linux систем утилита часто поставляется в комплекте дистрибутива, для Windows она доступна тут.
Вот такой командой можно просканировать подсеть:
nmap -sn 192.168.1.0/24
Помните, что такое сканирование может привлечь внимание систем безопасности, и к вам обязательно придет сотрудник соответствующей службы, если такая у вас в компании есть)
4. Утилита RVTools.
Мы часто пишем об этой утилите (последний раз писали тут). Она предназначена для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах, в том числе документировании.
Вот так выглядит инвентаризация виртуальных машин:
Удобно, что результаты можно сохранить не только в CSV, но и в нативный Excel-формат.
5. Утилита vDocumentation.
Об этой утилите мы писали вот тут. По сути, это набор сценариев, который позволяет через PowerCLI сгенерировать отчетность в форматах CSV или XLS, посвященную различным сторонам виртуальной инфраструктуры (сеть, хосты, кластеры vSAN и т.п.).
6. Утилита vCheck.
Об этой утилите для VMware vSphere мы уже писали вот тут. Кстати, недавно вышла ее версия для инфраструктуры виртуальных ПК VMware Horizon. vCheck - это PowerCLI-скрипт, который готовит отчетность по объектам окружения VMware vSphere и отсылает результат на почту администратора, из которого можно узнать о текущем состоянии виртуальной инфраструктуры и определить потенциальные проблемы.
Бесспорно, всего этого достаточно для сбора сведений об объектах виртуальной инфраструктуры, но не забывайте, что нужно еще иногда инвентаризировать и прочие объекты - интерфейсы iLO/iDRAC, физические коммутаторы, аппаратные сетевые экраны и прочие системы в датацентре.
На интересный момент обратил в своем блоге Mark Ukotic: ведь гостевая ОС Microsoft Windows Server 2019 недоступна при указании типа гостевой системы на платформе VMware vSphere:
Между тем, Windows Server 2019, вышедший еще в октябре прошлого года, полностью поддерживается в последних версиях VMware vSphere. Согласно статье KB 59222, для Windows Server 2019 нужно выбрать тип гостевой ОС Windows Server 2016 or later. Если подумать, это очень странно - ведь за прошедший с момента релиза год выходило немало апдейтов платформы VMware vSphere, хотя бы тот же vSphere 6.7 Update 3, но отдельной строчки для последней серверной платформы Microsoft в интерфейсе так и не появилось.
Однако если взглянуть на VMware Compatibility Guide и выбрать там в поле OS Family name систему Windows Server 2019, то мы увидим, что ESXi вполне ее поддерживает, начиная с версии 6.0.
Согласно политике поддержки VMware, если мы видим эту ОС в HCL, то она полностью поддерживается для работы в виртуальной машине на платформе vSphere.
То есть это чисто интерфейсная особенность, где поддержка Windows Server 2019 скрывается за окончанием пункта "or later".
На сайте проекта VMware Labs очередное обновление - вышла новая версия продукта Virtual Machine Compute Optimizer 2.0. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.
Напомним, что о первой версии данной утилиты мы писали летом этого года вот тут. Давайте посмотрим, что нового появилось в Virtual Machine Compute Optimizer 2.0:
Собираются приоритеты найденных несоответствий.
Вывод деталей найденных несоответствий.
Собирается информация о кластере, чтобы определить совместимость оборудования хостов на уровне кластера.
В отчет добавляется информация, если виртуальная машина использует разные физические pNUMA узлы, которые транслируются в гостевую ОС.
Добавляется информация об измененных расширенных настройках на уровне ВМ или хоста ESXi, касающихся представления pNUMA-узлов в гостевую ОС.
В отчет попадают ВМ, если у них число vCPU (с использованием гипертрэдов как vCPU) превышает число физических ядер CPU на хосте ESXi.
Возможность использовать отдельную функцию Get-OptimalvCPU для получения еще большей гибкости.
Скачать VM Compute Optimizer 2.0 можно по этой ссылке. Данный сценарий PowerCLI можно запустить различными способами, смотрите сопровождающий PDF (можно выбрать в комбобоксе при загрузке) для получения более детальной информации.
Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.
При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.
В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.
В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.
Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.
Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:
Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.
После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.
Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):
Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.
В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.
На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?
Системы кэширования работают в датацентре на всех уровнях - это сетевые коммутаторы, процессоры серверов и видеокарт, контроллеры хранилищ и т.п. Основная цель кэширования - предоставить высокопроизводительный ярус для приема операций ввода-вывода с высокой интенсивностью и малым временем отклика (это обеспечивают дорогие устройства), после чего сбросить эти операции на постоянное устройство хранения или отправить в нужный канал (для этого используются уже более дешевые устройства).
В кластере vSAN это выглядит вот так:
Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.
Общая производительность двухъярусной системы зависит как от производительности яруса хранения, так и параметров яруса кэширования (а именно скорость работы и его объем). Ярус кэширования позволяет в течение определенного времени принимать операции ввода-вывода с очень большой интенсивностью, превышающей возможности приема яруса хранения, но по прошествии этого времени буфер очищается, так как требуется время для сброса данных на уровень постоянного хранения.
С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):
Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).
Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:
Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.
С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:
Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.
Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.
На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:
Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.
На портале VMware Labs очередное обновление - вышла новая версия полезной утилиты VMware OS Optimization Tool, которая позволяет подготовить гостевые ОС к развертыванию и проводить тюнинг реестра в целях оптимизации производительности, а также отключение ненужных сервисов и запланированных задач.
Последний раз мы писали про эту утилиту в апреле прошлого года, давайте же посмотрим, что нового появилось в VMware OS Optimization Tool b1110:
Новая кнопка Common Options - позволяет быстро выбрать и настроить параметры для управления общей функциональностью. Теперь в интерфейсе можно с помощью данного блока выбрать нужный вариант тюнинга, не заглядывая в различные индивидуальные настройки в разных разделах.
Разделение Windows 10 на 2 шаблона, чтобы лучше обрабатывать различия между этими двумя версиями. Один шаблон для версий 1507-1803, а второй - для 1809-1909.
Улучшенные оптимизации для Windows 10, особенно для версий 1809 - 1909.
Исправлены многочисленные ошибки: сброс настроек при сохранении кастомизированных шаблонов, недоступные ссылки на вкладке Reference, недоступность Windows Store после оптимизации и многое другое.
Для новых версий Windows 10 была добавлена следующая функциональность для шаблонов:
Перемещение элементов между mandatory user и current user к default user.
Добавлено 34 новых элемента групповых политик, относящихся к OneDrive, Microsoft Edge, приватности, Windows Update, нотификациям и диагностике.
Добавлено 6 элементов в группу Disable Services.
Добавлен 1 элемент в группу Disable Scheduled Tasks.
Добавлен 1 элемент в группу HKEY_USERS\temp настроек реестра.
Добавлен 2 элемента в группу настроек HKLM.
Упрощено удаление встроенных приложений Windows (кроме Windows Store).
Скачать VMware OS Optimization Tool b1110 можно по этой ссылке.
Таги: VMware, VMachines, Optimization, Tools, Labs, Performance, Windows
Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.
Недавно мы писали о выходе серьезного обновления платформы виртуализации и доставки ПК и приложений в инфраструктуре предприятия VMware Horizon 7.9. Одновременно с этим вышли и обновления клиентов - VMware Horizon Clients 5.1. Также мы упоминали, что вышли новые версии User Environment Manager 9.8 и App Volumes 2.17. В App Volumes практически не появилось ничего нового, а вот в UEM 9.8 есть много всего интересного. Напомним, что о User Environment Manager 9.6 мы писали вот тут.
Давайте, посмотрим на список новведений и улучшений:
1. Дополнительные умные политики (Smart Policies).
Теперь можно включить или выключить воспроизведение аудио, которое применяется для протоколов Blast и PCoIP. Также через умные политики можно оптимизировать протокол Blast Extreme. Кроме того, можно настраивать механизм Drag and Drop. Для работы всех этих функций вам потребуется Horizon agent версии 7.9 или более поздней.
2. Поддержка условий для регулярных выражений.
Теперь в UEM 9.8 есть регулярные выражения при настройке умных политик, а также механизм определения условий, который очень ценен при составлении шаблонов поиска:
Пользователи продуктов AppSense и RES уже знакомы с этим механизмом регулярных выражений, теперь они появились и в UEM.
3. Новая опция Chrome Client при задании условия для Endpoint Platform.
Теперь для устройств Chrome появилось 2 новых опции - настройка Chrome ARC++ для Android-приложений, исполняемых на устройстве, а также Chrome Native для нативного клиента.
Для этой опции вам понадобится Horizon Client 5.1 или более поздней версии. Доступна эта возможность для устройств с протоколами Chrome Horizon Blast и PCoIP (Citrix ICA пока не поддерживается).
4. Поддержка Amazon FSx.
В этой версии UEM появилась полная поддержка файловой системы Amazon FSx for Windows File Server, которая представляет собой нативную облачную ФС для машин на базе Windows Server. Это упрощает развертывание инсталляций User Environment Manager для гибридных облаков, построенных на базе технологий VMware и Amazon (см. VMC on AWS).
Скачать VMware User Environment Manager 9.8 можно уже по этой ссылке, Release Notes доступны тут.
Еще очень давно, 8 лет назад, компания VMware развивала мобильный клиент (см. также тут) для управления инфраструктурой VMware vSphere, но забросила это дело на некоторое время.
И вот совсем недавно на сайте проекта VMware Labs появилось средство vSphere Mobile Client 1.1. Это очередной подход VMware к управлению виртуальной средой через мобильные приложения для iOS и Android.
Само собой, vSphere Mobile Client предоставляет лишь малую часть функций полноценного клиента (но для мобильных устройств это и не нужно), вот основные из них:
Просмотр информации и виртуальных машинах - просмотр статуса ВМ (включено/выключено), использования ресурсов и конфигурации машин.
Управление ВМ - операции с питанием (в том числе, перезагрузка). Возможность найти виртуальную машину с помощью поиска. Если вы свайпните влево карточку с виртуальной машиной, то получите скриншот ее консоли, который можно сохранить.
Мониторинг задач - можно "подписаться" на любую запущенную задачу и получать нотификации на телефон о том, когда она завершится. При этом неважно, что ваш девайс находится в неактивном режиме или в данный момент вы работаете с другим приложением.
Графики производительности - можно отслеживать использование ресурсов виртуальными машинами в реальном времени, либо в разрезе дня, недели, месяца или года назад. Счетчики включают в себя метрики CPU, памяти, хранилищ и сети. Также на дэшборде можно посмотреть общее использование ресурсов vCenter.
Ссылки на загрузку vSphere Mobile Client:
Android - до того, как устанавливать клиент, вам надо присоединиться к этой группе Google Groups, члены которой принимают участие в альфа-тестировании.
Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.
Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.
Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.
SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):
На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:
Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.
Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.
Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.
Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.
SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:
На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:
Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:
Так для Normal:
А так для High:
Если выберите вариант Custom, то дефолтно там будут такие значения:
Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.
Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:
После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:
Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.
Для тех, кто столкнулся с такой проблемой, Robert Szymczak написал полезный пост о том, как это сделать (но помните, что это неофициальная и неподдерживаемая процедура).
Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:
Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:
"xlarge": {
"cpu": 24,
"memory": 49152,
"host-count": 2000,
"vm-count": 35000,
"disk-swap": "50GB",
"disk-core": "100GB",
"disk-log": "25GB",
"disk-db": "50GB",
"disk-dblog": "25GB",
"disk-seat": "500GB",
"disk-netdump": "10GB",
"disk-autodeploy": "25GB",
"disk-imagebuilder": "25GB",
"disk-updatemgr": "100GB",
"disk-archive": "200GB",
"required-disk-space": "1180GB",
"label": "X-Large vCenter Server with Embedded PSC",
"description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
}
Таким образом вы поймете, на какие именно конфигурации нужно изменить компоненты виртуальной машины с vCenter. Перед изменением конфигурации сделайте снапшот машины vCSA, который сохранит параметры ее виртуального аппаратного обеспечения.
Теперь переходим, собственно, к изменению самой конфигурации:
1. Увеличение CPU и памяти (RAM).
Остановите машину.
Хорошая идея - вывести ее ESXi-хост из кластера DRS.
Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.
2. Увеличение диска ВМ с сервером vCSA.
Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.
Примерно так это выглядит для vCenter 6.7 Update 2:
Назначение
Позиция в фале JSON
Номер VMDK
Слот SCSI
root / boot
n/a
1
0:0
tmp
n/a
2
0:1
swap
1
3
0:2
core
2
4
0:3
log
3
5
0:4
db
4
6
0:5
dblog
5
7
0:6
seat
6
8
0:8
netdump
7
9
0:9
autodeploy
8
10
0:10
imagebuilder
9
11
0:11
updatemgr
10
12
0:12
archive
11
13
0:13
Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.
Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.
После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.
Это гостевой пост компании ИТ-ГРАД, предоставляющей виртуальные машины из облака в аренду. VMware обновили свой гипервизор ESXi. Теперь скорость работы виртуальных графических процессоров под его управлением сопоставима с возможностями их bare metal реализаций — разница составляет всего 3%. Рассказываем, как компании удалось этого добиться...
Вопрос этот важен, так как многие пользуются лимитами для виртуальных машин на уровне хранилищ vSAN, но не хотят, чтобы в случае сбоя ресинхронизация кластера или перемещение машин происходили с ограничениями, которые могут увеличить время восстановления в разы.
Ответ тут прост - нет, не влияет. Лимиты устанавливаются на уровне гостевой системы для VMDK-дисков виртуальных машин и сопутствующих объектов (например, снапшоты, своп и т.п.), поэтому операции, которые проводятся извне со стороны платформы, в этом не участвуют.
Таким образом, лимиты для виртуальных машин можно ставить без ограничений и не заботиться о том, что это повлияет на время восстановление кластера и отдельных ВМ в случае сбоя. Операции SVMotion также затронуты не будут.
У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.
Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:
После того, как вы запустите предпроверку Update Manager, вы получите отчет с предупреждениями о фактах, мешающих дальнейшим обновлениям:
Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:
Номер
Текущий статус
Рекомендуемое действие
Описание
1
Отключен ли DPM?
Отключите DPM в кластере
Если на хосте нет виртуальных машин, то механизм DPM может перевести хост в режим standby во время или до обновления. Вследствие этого, DPM может не начать процесс обновления хоста.
2
Включен ли DRS?
Включите DRS в кластере
Именно DRS позволяет серверу vCenter смигрировать ВМ на другие хосты ESXi, чтобы обновить целевой хост-сервер.
3
Отключен ли HA admission control?
Отключите HA admission control
HA admission control предотвращает миграцию ВМ средствами vMotion, в результате которой не выполняются правила доступности слотов. Перед обновлением этот механизм лучше отключить.
4
Включен ли EVC в кластере?
Включите EVC в кластере
EVC позволяет убедиться, что все хосты в кластере презентуют одинаковый набор инструкций CPU виртуальным машинам. Это позволяет гарантировать, что все они могут перемещаться на любой хост кластера средствами vMotion во время эвакуации машин с обновляемого хоста ESXi.
5
Успешны ли проверки vSAN health check?
Проверьте страницу vSAN Health Check на наличие проблем
Проверки vSAN Health Check представляют собой набор тестов для хостов ESXi, составляющих кластер vSAN (например, тесты доступности хранилищ во время обновления). Они должны завершиться успешно перед началом процедуры обновления хостов.
Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:
Номер
Текущий статус
Рекомендуемое действие
Описание
1
К ВМ привязан привод CD/DVD
Отключите привод CD/DVD
Это редкая, но случающаяся проблема, когда такие приводы используются, например, для монтирования ISO-образов.
2
К ВМ привязан floppy-драйв
Отключите привод floppy
Очень редко, но бывает.
3
Для ВМ включена технология FT
Отключите Fault Tolerance для ВМ
Технология Fault Tolerance не позволяет VUM обновлять ВМ.
4
На ВМ установлен VMware vCenter Server, при этом DRS в кластере отключена
Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion
vCenter управляет компонентом VUM, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.
5
На ВМ установлен VMware vSphere Update Manager, при этом DRS в кластере отключена
Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion
vCenter управляет процессом обновления, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.
Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.
В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.
Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:
Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:
Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.
Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).
Помните, что при апгрейде VMware Tools вам может потребоваться перезагрузка виртуальных машин и их гостевых ОС. Также вы можете использовать приведенный выше сценарий для нескольких ВМ в одной папке:
Через vSphere Client тулзы также прекрасно обновляются:
Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.
Еще одна опция - настроить обновления тулзов в настройках виртуальной машины:
Иногда администраторы гостевой системы имеют эксклюзивный доступ к ней (например, админы бизнес-критичных баз данных) и контролируют все происходящие в ней события. Для этого надо настроить их взаимодействие с машиной как указано в KB 2007298.
В этом случае они получат нотификацию о новой версии VMware Tools из трея, либо могут проверить наличие обновлений самостоятельно с помощью команд:
Не так давно мы писали о функции Site Locality в кластере VMware vSAN и некоторых ситуациях, когда эту функцию полезно отключать. Недавно Дункан Эппинг еще раз вернулся к этой теме и рассказал, что при использовании растянутых кластеров VMware vSAN надо иметь в виду некоторые особенности этого механизма.
При создании растянутого кластера вам предоставляют опции по выбору уровня защиты данных RAID-1 или RAID-5/6 средствами политики FTT (Failures to tolerate), а также позволяют определить, как машина будет защищена с точки зрения репликации ее хранилищ между датацентрами.
Некоторые дисковые объекты машин вы можете исключить из растянутого кластера и не реплицировать их между площадками. Такая настройка в HTML5-клиенте выглядит следующим образом:
В старом интерфейсе vSphere Web Client это настраивается вот тут:
Смысл настройки этих политик для виртуальной машины в том, чтобы вы могли однозначно определить размещение ее дисковых объектов, так как если у нее несколько виртуальных дисков VMDK, то если вы не зададите их локацию явно - может возникнуть такая ситуация, когда диски одной машины размещаются в разных датацентрах! Потому что при развертывании ВМ решение о размещении принимается на уровне дисковых объектов (то есть на уровне виртуальных дисков), которые по каким-то причинам могут разъехаться в разные сайты, если вы выберите первый пункт на первом скриншоте.
Это, конечно же, со всех сторон плохо, особенно с точки зрения производительности.
Если такая машина работает не в растянутом кластере vSAN, то в случае, если произойдет разрыв между площадками - часть дисков в гостевой системе станет недоступна, что неприемлемо для приложений и ОС.
Поэтому всегда убеждайтесь, что машина и ее дисковые объекты всегда находятся на одном сайте, для этого задавайте их локацию явно:
Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?
Также этот вариант использования может быть востребован, когда вам требуется доступ к управляющим компонентам посредством таких интерфейсов, как PowerCLI, или развертывание виртуальных сервисов с помощью утилиты OVFTool. Вильям Лам написал об этом хорошую статью, и мы приведем здесь ее основные моменты.
Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.
Процедура для NSX-V
В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.
Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).
Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":
Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).
В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:
Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:
После этого вы можете залогиниться в виртуальную машину и использовать средства управления платформой vSphere, например, применять утилиту импорта виртуальных модулей OVFTool, как рассказано тут.
Процедура для NSX-T
В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.
В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.
Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:
Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.
Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:
Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).
Не забывайте нажать кнопку Publish, чтобы сохранить и применить правило сетевого экрана.
Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).
Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):
После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).
Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:
В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:
Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.
С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:
vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.
Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:
vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.
Будем надеяться, что эта ситуация в будущем изменится.
Таги: VMware, vSphere, Memory, PMEM, Intel, VMachines, HA, DRS
RSS
